Section: Application Domains

Application Domains

This section illustrates the scientific challenges described above through a use-case scenario for dynamic middleware technologies in an ambient environment. An end-user has a mobile phone from which he/she can read emails, write new messages, and print documents. Printer devices and network access points are spread across the environment, thus availability varies based on user location. We illustrate that the dynamic service-oriented architecture that we envision fits at three levels of service provisioning granularities. Specifically, we consider dynamic SOA at the application level, at the operating system level and at the hardware radio communication level.

Application-level adaptation

The user launches an email application and wants to print a message. The dynamic service architecture is able to discover the “best” printing service available from the near environment. When the user moves to another room, the printing service can discover a new device and redirect the printing jobs to it. This usage emphasizes that, unless the user needs a printing service, the corresponding implementation is never loaded into the device memory. This “on-demand” service provisioning is the main point of dynamic service oriented architecture. When the user does not need printing anymore, the architecture can transparently remove the implementation to reclaim some memory at the benefit of other services. The challenge here is to formalize the process: how do we decide what the “best” service is, in a given context ? what does “best” mean ?

Operating system

Our user just composed an heavy email with some documents attached. At the time when the email client is sending message data through a WiFi connection, the user moves to another room with no WiFi connectivity. The operating system scans the available network interfaces and finds a 3G connection. In this case, it first dynamically downloads the available implementation, then changes the transport layer to 3G, and finally transmits the remaining bits of the email message without interrupting the user. The dynamic SOA enables reconfiguration of operating systems much like microkernels do, albeit the service granularity focuses on coarse-grained components to be mixed and matched. Finding the best service at launch time, or finding and switching to a better service at run-time is another key element of dynamic SOA for ambient environments. This implies comparison and evaluation of different but similar service implementations, which in turn requires some sort of “formal” behavioral description of these components. How do we get these descriptions ? What is the best language to reason about these models ?

Software-defined radio

One of the goals of software-defined radio technologies is to dynamically reconfigure hardware telecommunication layers depending on the incoming radio signal shapes. Current communication systems use specific hardware chips for each kind of signal processing. On the other hand, the software-defined radio approach tries to use a generic chip layer that can be reconfigured “on-demand”, leveraging the observation that the signal processing chain itself is similar across radio signal shapes. The various signal-specific functional units are brought together at run-time when some kind of received signal is to be processed. Dynamic service oriented architecture perfectly match this type of generic hardware approach. Although this is not possible at the moment, mainly due to response time delays, an efficient dynamic software architecture would be of great interest for the software radio environment. The question is, how to guarantee efficiency and correctness at this level of abstraction ?

Dynamic service-oriented architectures need not be confined to the world of heavyweight high-end systems. The goal of Amazones is to address the challenges which prevent dynamic SOA to be used in embedded environments : how to bring dynamicity to resource-constrained devices, how to express and validate properties on service components, and how to obtain these properties on an existing system.

Through these different use-cases we quickly showed that our approach can match various goals that spread across different application and system layers. Of course, the more constrained the hardware layer we consider, the more technical difficulties we meet, but the scientific concepts are still the same. These concepts are the objectives Amazones focuses on.